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RESOURCE RESERVATION IN 3G OR FUTURE GENERATION 
TELECOMMUNICATION NETWORK (IV) 
Cross-Reference To Related Application 

This application claims priority of European Patent Application No. 
5 00303897.3, which was filed on May 9, 2000. 
Background of the Invention 
1. Field of the Invention 

This invention relates to telecommunications networks operating the 
Internet Protocol (IP), and relates especially to a method of reserving 
10 resources. 

2> Description of Related Art 

In third generation (3G) telecommunications networks, such as 
Universal Mobile Telecommunication System (UMTS), broad bandwidth is 
provided for services such as data and multimedia in addition to voice. An 
15 obvious need is that required Quality of Service (QoS) should be provided to 
users, but in IP networks, if contention for resources is not resolved, then 
QoS cannot be guaranteed. 

In IP networks or the Internet in general, Resource reSerVation 
Protocol (RSVP) is used to allow the network to reserve resources so as to 
20 provide QoS. RSVP can be used for QoS control locally or it may be used 
across IP networks. 

RSVP is an end-to-end protocol and is illustrated in Figure 1. A 
transmitting user 10 sends to a receiving user 12 a message PATH. The 
PATH message carries the traffic characteristics information such as Tspecs 
25 to indicate the traffic behavior that is to be sent from the user 10. When the 
receiving user receives the PATH message, it sends a RESV message which 
contains QoS requests such as FlowSpecs. In practice, the transmitting 
and receiving users 10, 12 can be located remotely so that PATH and RESV 
messages pass through several nodes in UMTS. As each node receives either 
30 of the messages, it makes a decision as to whether adequate resources in that 
node can be reserved. If this is possible, then the messages are relayed to the 
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next hop for the PATH message and to the previous hop for the RESV 
message. When the RESV message reaches the transmitting user 10, it 
begins to transmit data. 

Periodic refresh messages are sent subsequently to maintain the QoS 
5 status at each node in which it has been set up. 

At the TSG-SA Working Group 2 meeting no. 12 in Tokyo, 6-9 March 
2000 a disclosure was made by applicant of arrangements in which a mobile 
system using RSVP can communicate across a GPRS/UMTS network with 
another RSVP user; a proxy activated by the mobile receives and processes 
10 PATH messages and generates RESV messages in return. 

Applicant's co-pending European patent application no. [Lucent 
Case Name/No. X. Chen 11/ IDS No. 122413] filed on even date describes an 
inventive method in which RSVP messages are filtered at a mobile and at a 
Serving GPRS Support Node (SGSN) or a Gateway GPRS Support Node 
15 (GGSN), and the mobile and the support node are arranged to activate 
Packet Data Protocol (PDP) Context Activation Procedure. However, conflicts 
can arise in certain circumstances. 
Summary of the Invention 

It is an object of the invention to provide a method of reserving 
20 resources in third or future generations of wireless mobile networks such as 
UMTS which has no or minimal impact on existing architecture or QoS 
procedures, that overcomes the aforementioned conflict. 

According to the invention, in a third or future generation 
telecommunication network, a method of allocating resources for user traffic 
25 passing between a mobile terminal and a remote user, characterized in that 
unidirectional Resource reSerVation Protocol (RSVP) messages arecompared 
so as to detect any previous RSVP message for that session. 

Preferably a flag is arranged to indicate that an RSVP message for 
that session has already been sent. 
30 Brief Description of the Drawings 

In the accompanying drawings, Figure 1 illustrates the operation of 



2 



Chen 13 



RSVP. The invention will be described by way of example only, with 
reference to figures 2-5 in which:- 

Figure 2 illustrates schematically the UMTS QoS architecture for the 
control plane; 

5 Figure 3 illustrates the interchange of messages in an uplink; 

Figure 4 illustrates the interchange of messages in a downlink; 
Figure 5 illustrates the uplink interchange of messages in an end-to- 
end session; and 

Figure 6 illustrates the interchange of messages in a downlink 

10 direction. 

Detailed Description 

In Figure 2 the UMTS 20 comprises a Core Network (CN) 22 formed by 
a Gateway GPRS Support Node (GGSN) 24 and a Serving GPRS Support 
Node (SGSN) 26; there is also a UMTS Terrestrial Radio Access Network 

15 (UTRAN) 28. A MT 30 communicates with the UTRAN 28 across a radio 
interface. The MT 30 is connected to Terminal Equipment (TE) 32 which 
may run non-UMTS specific applications. The MT 30 is UMTS specific, and 
is capable of processing the traffic from the TE 32 to channel it appropriately 
to the UMTS, usually to the radio access network. 

20 The GGSN 24 communicates with an External Network 40. 

The UMTS 20 operates the application-specific Packet Data Protocol 
(PDP) context as usual to negotiate the QoS and activate the QoS control 
between the MT 30 and UMTS network 20. 

Figure 3 illustrates traffic QoS in the uplink direction. RSVP 

25 messages are terminated only at the MT 30. The RSVP processing entity in 
the MT 30 is triggered by a PATH message from TE 32. In response, the MT 
30 filters the message, analyses the RSVP parameters carried in the PATH 
message, and takes a decision whether to modify an existing secondary PDP 
context or to create a new secondary PDP context, to provide an updated QoS 

30 status. The secondary PDP context is then create/modified using the existing 
PDP Context Control procedures. If the PATH message is a first-time PATH 
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message, a new secondary PDP context is created. If the PATH message is a 
refresh message with no modified QoS parameter, then no action is taken. 
The activate secondary PDP context message is sent by the MT 30 across the 
UTRAN 28 to the SGSN 28, which generates a create/modify PDP context 
5 Request message and passes it to the GGSN 24. Return messages from the 
GGSN are processed similarly by the SGSN, and the MT 30 filters the 
message and passes a RESV message to the TE 32. The TE 32 may send a 
refresh PATH message and receive a refresh RESV message. 

An important feature of RSVP is its um-directional QoS request 

10 delivery. Specifically, the QoS status in the uplink direction set up by using 
RSVP does not apply to the QoS status in the downlink direction. This 
means that a QoS status that applies in both uplink and downlink requires- 
two separate RSVP session set-up processes so as to be in line with the two 
way QoS status as contained by the PDP context of UMTS. This increases 

15 the QoS session set-up time and further complicates the QoS control and 
management in separate directions, because each direction needs to be 
controlled and maintained separately. 

However, there is a problem which may be termed a "racing" problem 
because an RSVP terminal may not be UMTS aware, i.e. it may not be aware 

20 of a two-way nature of UMTS secondary PDP context. Then each end of an 
RSVP session may send RSVP messages independently from its remote peer. 
This means that the GGSN 24 will receive two PATH/RESV messages, each 
of which applies for each direction (one for uplink and the other for 
downlink). The same "racing " problem occurs when the RSVP messages are 

25 terminated only at the MT 30. 

This racing problem has not previously been recognized. In the present 
invention the problem is resolved by checking if there is any existing 
secondary PDP context associated with RSVP QoS status by matching the 
end point information contained in the PDP context in comparison with the 

30 incoming RSVP messages. If no match is found, then no action will be taken 
upon receiving an RSVP message which will then be transparently delivered 
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to the remote peer end as before. 

In Figure 3 the points at which such message comparison takes place, 
in the MT 30, are indicated at M. 

In Figure 4, which illustrates a downlink, ESVP is terminated only at 
5 the MT 30. The session is initiated from the External Network 40 and 
message processing is similar to that in Figure 3. The message comparison 
points, which may be in the MT 30 or the GGSN 24, are also indicated at M. 

Figure 5 illustrates a variation in which a RSVP session is used end-to- 
end and is terminated at the MT 30 and the GGSN 24. The assumption is 
10 that TE 32 intends to set up an RSVP session with its remote peer, which 
also uses RSVP signaling, in the External Network 40. The Figure shows 
RSVP activated QoS in the uplink direction. 

When the MT 30 received a PATH message from TW 32, it checks to see if a 
PDP context exists for this RSVP session. If it does, the MT 30 triggers the 
15 Modify PDP context message if there is a change in QoS parameters. 

When the PATH message is received at the GGSN 24, it uses this 
information, again along with relevant local configuration, to see if QoS 
Negotiated is the same as QoS Requested. The PATH message is then sent to 
the external network. Radio Access Barrier (RAB) negotiation can take place 
20 between the SGSN 24 and the UTRAN 28 if QoS Negotiated is different from 
QoS Requested. Finally, the RESV message returned from the external 
network is filtered by the GGSN, which creates or modifies a PDP Context 
request message, which is sent to the MT30. 

The message comparison points in the MT30 and the SGSN24 are 
25 again indicated at M. 

Figure 6 shows the end-to-end situation for the QoS control in the 
downlink direction with filtering in the MT and GGSN. 

As before, the message comparison points to prevent the racing 
problem are indicated at M. 
30 To overcome the racing problem, the comparisons at the point M can be 

made, for example, in two ways, both involving use of a flag. 
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In a first arrangement, a flag is made available in every PATH and 
RESV message by addition of a flag bit. 

For an MT-only terminated arrangement, for every session, the flag is 
set by the MT 30 the first time a RSVP message is sent or received by the MT 
5 30. The flag is sent to the receiving end in the RSVP message for this session, 
and the receiving end recognizes that it does not need to send a return RSVP 
message for this session. The message in which the flag is set may be either a 
PATH message or a RESV message. 

If the flag has not been set, then no RSVP message has been sent and 
10 there can be no racing problem. 

For an MT and support node terminated arrangement, either the MT 
or ghe SGSN/GGSN can set the flag. In this arrangement, the MT 30, the 
GGSN 24 and the SSGN 26 need a small modification so that it/they can set 
the flag bit and recognize when the bit has been set in a received message, 
15 and to act (or not act) appropriately. 

In a second arrangement, a session flag is made available in PDP 
Context, which carries all the information about a session. The session 
flag can be set by either the MT 30 or the GGSN 24 or the SGSN 26. 

For example, when the GGSN 24 receives a first RSVP message 
20 (whether it is a Path or a RESV message) it sets the session flag in PDP 
context; the RSVP message is sent by the GGSN in a first direction to the 
remote end; it is to be understood that the remote end does not receive a flag. 
When a return RSVP message in the opposite direction is received by the 
GGSN 24, it checks if the flag is set for that session; if the flag is set, the 
25 GGSN discards any further RSVP messages for that session, therefore the 
racing problem is avoided. 

The GGSN also checks to see if the QoS requirement is the same as in 
the PDP Context sent out; if the QoS requirement is higher, the GGSN 
actions the Modify Existing PDP context protocol. 
30 Usually a customer will have the option of deciding whether to change 

the QoS if it is lower than the present QoS requirement. 
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In the first arrangement according to the invention with a flag in the 
RSVP message, the MT 30 prevents the racing problem and the remote end 
does not pass on the RSVP message. The first arrangement can be applied to 
messages as shown in Figs 3 and 4 in which RSVP messages are filtered in 
5 the MT 30 only. 

In the second arrangement according to the invention with the flag in 
the PDP context, the GGSN prevents the racing problem and the remote end 
does not pass on the RSVP message. The second type of flag is applicable to 
messages as shown in Figures 5 and 6 in which the RSVP messages are 
10 filtered at the MT 30 and the GGSN 24. 

By such comparisons at any of the indicated positions, the aforesaid 
"racing" problem is overcome. 

Either a RSVP message can be intercepted in the MT and the SGSN or 
GGSN 26, the MT or support node then initiating PDP context activation 
15 procedure, as described in applicant's copending European patent application 
no. [Lucent Case Name/No. X. Chen 11/ IDS No. 122413] filed on even date, 
or the RSVP messages can be "piggybacked" in an IP packet , as set out in 
applicant's application no. 00301782.9 filed on 3 March 2000. 
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